Dans des discussions récentes entre acteurs du PLM (mélangeant responsables PLM, intégrateurs et éditeurs), j’ai récemment lu que le MDM (Master Data Management) n’était qu’une « opportunité de business pour éditeurs imaginatifs ». J’étais choqué par ce constat. J’ai montré à travers plusieurs articles pourquoi à moyen-long termes, il allait falloir tendre vers l’utilisation de MDM dans les écosystèmes IT d’entreprises afin d’en finir avec la problématique de propriété de la donnée. Il faut que les spécialistes PLM et les spécialistes ERP fassent le deuil de la propriété de données, pour réfléchir en termes de services et de fonctionnalités métiers.
La crainte de perdre le contrôle des données
C’est toujours la même histoire avec les discussions de frontière ERP/PLM, il y a une bagarre sur qui gère quelles données. Et on finit, en général par faire des compromis et des intégrations pour finir souvent avec des données dupliquées et/ou des interdépendances de systèmes. Dans la vidéo ci-dessous de PTC, la personne termine en indiquant que le PLM concerne la propriété intellectuelle du produit et que l’ERP gère plutôt le produit réel. Qu’en est-il alors du concept de gestion de cycle de vie du produit? Il aurait peut-être fallu appeler cette solution PCM for Product Conception Management.
La raison principale de toutes ces problématiques à mon avis, est que les éditeurs ERP et PLM sont encore trop proches du stockage de la donnée. Leur champ d’application est trop important. Quand vous évaluez des solutions PLM (comme pour l’ERP), vous devriez principalement chercher à savoir lequel des logiciels évalués assure le mieux les fonctionnalités nécessitées par vos métiers. Vous ne voulez pas avoir à évaluer des questions de performances d’architecture du base de données ou leurs capacités à extraire vos données.
Se poser la question de la valeur ajoutée d’un MDM
Alors qu’est-ce que doit vous apporter un MDM? Ce que j’attends d’un MDM, c’est qu’il gère de manière optimale les données que je lui donne afin de répondre au mieux aux requêtes que je lui soumets.
- Opération à partir d’un grand nombre d’enregistrements:
Si je dois faire un calcul de coûts d’un système de 10000 pièces, il doit trouver la technologie de base de données la plus adéquate pour faire une opération sur une propriété d’un grand nombre d’enregistrements.
- Navigation entre enregistrements liés
Si je lui demande de me réaliser une analyse d’impact qui doit pouvoir naviguer dans des relations de nomenclatures physiques et fonctionnelles, il aura sûrement besoin de faire appel à d’autres technologies telles que les bases de données graphiques (exemples)
- Publication de données PLM
Si j’ai besoin de publier un grand nombre d’informations, j’aurai sûrement besoin de me rapprocher de standards de publication pour la plupart définis en XML. Et ainsi sûrement utiliser une technologie plus proche du XML (exemples)
Un Fantasme? Bien sûr !
Alors oui, c’est un fantasme. Je n’ai pas encore eu beaucoup d’exemples de MDM se nourrissant de multiples technologies de bases de données. Mais il n’y a rien d’opportuniste c’est une possibilité de permettre aux responsables métiers de choisir des solutions PLM en maîtrisant la sélection sur des critères basés sur leur expertise.
La vidéo ci-dessous présente le MDM principalement pour sa maîtrise de la qualité de données.
Je présenterai dans un futur article le couple MDM-ESB qui permettra de passer dans une ère de fourniture de services aux différentes applications métiers de l’entreprise.
Bonjour, bon article. Le MDM en tant que chef d’orchestre du SI et référentiel de données est une évidence, et il est bien dommage que tant de projets « PLM » essayent d’inclure le socle fonctionnel du MDM, avec toutes les maladresses et désillusions que cela amène.
Le bon sens conduirait à mettre en place un noyau MDM, connecté à l’ERP, intégrant les multiples « PDM » nécessaires aux applications d’ingénieries.
Le « PLM » en tant que référentiel des données du « produit » est le terrain de jeu des opportunistes.
Les technologies pour le MDM existent, à travers le XML, l’iso 15926 et son modèle sémantique, les moteurs de workflows et les techno ETL. Ne reste que la volonté de replacer chaque brique (système) à sa place pour réellement apporter de la plus-valu (ROI) à cette chaine d’information.
Tout à fait d’accord ! La difficulté va être de savoir qui va lancer cette démarche? un éditeur puissant qui va fournir cette couche MDM avec assez d’évangélisation pour expliquer qu’elle doit être commune au PLM, à l’ERP et autres applications? Ou des entreprises qui commencent elles même à implémenter ce genre de solution, rentrant alors en conflit avec certains editeurs en leur demandant de fonctionner avec un MDM (dans ce cas surement passer par l’appui d’association d’utilisateurs). Je pense que l’on va de toute façon avancer dans cette direction, reste le quand et comment !
[…] Le MDM n’est pas un simple fantasme d’opportuniste […]